자바스크립트 모듈 페더레이션 마스터하기: 공유 스코프와 의존성 공유의 힘

빠르게 발전하는 웹 개발 환경에서 확장 가능하고 유지보수 가능한 애플리케이션을 구축하려면 정교한 아키텍처 패턴을 채택해야 하는 경우가 많습니다. 그중에서도 마이크로프론트엔드 개념은 상당한 주목을 받았으며, 이를 통해 팀은 애플리케이션의 각 부분을 독립적으로 개발하고 배포할 수 있습니다. 이러한 독립적인 단위들 간의 원활한 통합과 효율적인 코드 공유를 가능하게 하는 핵심에는 Webpack의 모듈 페더레이션 플러그인이 있으며, 그 강력함의 핵심 요소는 바로 공유 스코프(shared scope)입니다.

이 종합 가이드에서는 자바스크립트 모듈 페더레이션 내의 공유 스코프 메커니즘을 심층적으로 다룹니다. 우리는 그것이 무엇인지, 왜 의존성 공유에 필수적인지, 어떻게 작동하는지, 그리고 효과적으로 구현하기 위한 실용적인 전략을 탐구할 것입니다. 우리의 목표는 개발자들이 이 강력한 기능을 활용하여 다양한 글로벌 개발팀 전반에 걸쳐 성능을 향상시키고, 번들 크기를 줄이며, 개발자 경험을 개선할 수 있는 지식을 갖추도록 하는 것입니다.

자바스크립트 모듈 페더레이션이란 무엇인가?

공유 스코프에 대해 알아보기 전에, 모듈 페더레이션의 기본 개념을 이해하는 것이 중요합니다. Webpack 5와 함께 도입된 모듈 페더레이션은 자바스크립트 애플리케이션이 별도로 컴파일된 애플리케이션 간에 코드(라이브러리, 프레임워크 또는 전체 컴포넌트 등)를 동적으로 공유할 수 있게 해주는 빌드 타임 및 런타임 솔루션입니다. 이는 여러 개의 개별 애플리케이션('remotes' 또는 'consumers'라고도 함)이 'container' 또는 'host' 애플리케이션으로부터 코드를 로드할 수 있고, 그 반대도 가능하다는 것을 의미합니다.

모듈 페더레이션의 주요 이점은 다음과 같습니다:

• 코드 공유: 여러 애플리케이션에 걸쳐 중복된 코드를 제거하여 전체 번들 크기를 줄이고 로드 시간을 개선합니다.
• 독립적인 배포: 팀은 대규모 애플리케이션의 다른 부분을 독립적으로 개발하고 배포하여 민첩성과 더 빠른 릴리스 주기를 촉진할 수 있습니다.
• 기술 불가지성: 주로 Webpack과 함께 사용되지만, 어느 정도 다른 빌드 도구나 프레임워크 간의 공유를 용이하게 하여 유연성을 증진시킵니다.
• 런타임 통합: 런타임에 애플리케이션을 구성할 수 있어 동적 업데이트와 유연한 애플리케이션 구조를 가능하게 합니다.

문제점: 마이크로프론트엔드에서의 중복 의존성

여러 마이크로프론트엔드가 모두 React와 같은 인기 있는 UI 라이브러리나 Redux와 같은 상태 관리 라이브러리의 동일한 버전에 의존하는 시나리오를 생각해 보십시오. 공유 메커니즘이 없다면, 각 마이크로프론트엔드는 이러한 의존성의 자체 복사본을 번들링할 것입니다. 이는 다음과 같은 문제로 이어집니다:

• 비대해진 번들 크기: 각 애플리케이션이 공통 라이브러리를 불필요하게 복제하여 사용자의 다운로드 크기가 커집니다.
• 메모리 소비 증가: 브라우저에 로드된 동일한 라이브러리의 여러 인스턴스가 더 많은 메모리를 소비할 수 있습니다.
• 일관되지 않은 동작: 애플리케이션 간에 공유되는 라이브러리의 버전이 다르면 미묘한 버그와 호환성 문제가 발생할 수 있습니다.
• 네트워크 리소스 낭비: 사용자가 다른 마이크로프론트엔드 사이를 이동할 경우 동일한 라이브러리를 여러 번 다운로드할 수 있습니다.

바로 이 지점에서 모듈 페더레이션의 공유 스코프가 이러한 문제들에 대한 우아한 해결책을 제시하며 중요한 역할을 합니다.

모듈 페더레이션의 공유 스코프 이해하기

모듈 페더레이션 플러그인 내의 shared 옵션을 통해 구성되는 공유 스코프는 여러 독립적으로 배포된 애플리케이션이 의존성을 공유할 수 있게 하는 메커니즘입니다. 구성되면, 모듈 페더레이션은 지정된 의존성의 단일 인스턴스만 로드되어 이를 필요로 하는 모든 애플리케이션에서 사용할 수 있도록 보장합니다.

핵심적으로, 공유 스코프는 공유 모듈을 위한 전역 레지스트리 또는 컨테이너를 생성하여 작동합니다. 애플리케이션이 공유 의존성을 요청하면, 모듈 페더레이션은 이 레지스트리를 확인합니다. 만약 의존성이 이미 존재한다면(즉, 다른 애플리케이션이나 호스트에 의해 로드되었다면), 기존 인스턴스를 사용합니다. 그렇지 않으면, 의존성을 로드하고 나중에 사용할 수 있도록 공유 스코프에 등록합니다.

일반적인 구성은 다음과 같습니다:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ... other webpack configurations
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        'app1': 'app1@http://localhost:3001/remoteEntry.js',
        'app2': 'app2@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

공유 의존성을 위한 주요 구성 옵션:

• singleton: true: 아마도 가장 중요한 옵션일 것입니다. true로 설정하면, 모든 소비 애플리케이션에 걸쳐 공유 의존성의 단일 인스턴스만 로드되도록 보장합니다. 여러 애플리케이션이 동일한 싱글톤 의존성을 로드하려고 시도하면, 모듈 페더레이션은 그들에게 동일한 인스턴스를 제공합니다.
• eager: true: 기본적으로 공유 의존성은 지연 로드(lazily loaded)됩니다. 즉, 명시적으로 임포트되거나 사용될 때만 가져옵니다. eager: true로 설정하면, 즉시 사용되지 않더라도 애플리케이션이 시작되자마자 의존성이 강제로 로드됩니다. 이는 프레임워크와 같은 중요한 라이브러리가 처음부터 사용 가능하도록 보장하는 데 유용할 수 있습니다.
• requiredVersion: '...': 이 옵션은 공유 의존성의 필수 버전을 지정합니다. 모듈 페더레이션은 요청된 버전을 맞추려고 시도합니다. 만약 여러 애플리케이션이 다른 버전을 요구하면, 모듈 페더레이션은 이를 처리하기 위한 메커니즘을 가지고 있습니다(나중에 논의).
• version: '...': 공유 스코프에 게시될 의존성의 버전을 명시적으로 설정할 수 있습니다.
• import: false: 이 설정은 모듈 페더레이션에게 공유 의존성을 자동으로 번들링하지 않도록 지시합니다. 대신, 외부에서 제공될 것으로 예상합니다(이는 공유 시 기본 동작입니다).
• packageDir: '...': 공유 의존성을 해결할 패키지 디렉토리를 지정하며, 모노레포에서 유용합니다.

공유 스코프가 의존성 공유를 가능하게 하는 방법

실용적인 예제를 통해 그 과정을 분석해 보겠습니다. 메인 '컨테이너' 애플리케이션과 두 개의 '원격' 애플리케이션, `app1`과 `app2`가 있다고 상상해 보십시오. 세 애플리케이션 모두 `react`와 `react-dom` 버전 18에 의존합니다.

시나리오 1: 컨테이너 애플리케이션이 의존성을 공유하는 경우

이 일반적인 설정에서, 컨테이너 애플리케이션은 공유 의존성을 정의합니다. 모듈 페더레이션에 의해 생성된 `remoteEntry.js` 파일은 이러한 공유 모듈을 노출합니다.

컨테이너의 Webpack 설정 (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

이제, `app1`과 `app2`는 이러한 공유 의존성을 소비하게 됩니다.

`app1`의 Webpack 설정 (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

`app2`의 Webpack 설정 (`app2/webpack.config.js`):

`app2`의 구성은 `app1`과 유사하며, `react`와 `react-dom`을 동일한 버전 요구사항으로 공유하도록 선언합니다.

런타임에서의 작동 방식:

1. 컨테이너 애플리케이션이 먼저 로드되어, 공유된 `react` 및 `react-dom` 인스턴스를 모듈 페더레이션 스코프에서 사용 가능하게 만듭니다.
2. `app1`이 로드될 때, `react`와 `react-dom`을 요청합니다. `app1`의 모듈 페더레이션은 이들이 공유되고 `singleton: true`로 표시된 것을 확인합니다. 전역 스코프에서 기존 인스턴스를 확인합니다. 만약 컨테이너가 이미 로드했다면, `app1`은 해당 인스턴스를 재사용합니다.
3. 마찬가지로, `app2`가 로드될 때도 동일한 `react` 및 `react-dom` 인스턴스를 재사용합니다.

이 결과로 브라우저에는 `react`와 `react-dom`의 단 하나의 복사본만 로드되어 총 다운로드 크기가 크게 줄어듭니다.

시나리오 2: 원격 애플리케이션 간 의존성 공유

모듈 페더레이션은 또한 원격 애플리케이션들이 서로 의존성을 공유할 수 있도록 합니다. 만약 `app1`과 `app2`가 컨테이너에 의해 공유되지 *않는* 라이브러리를 사용한다면, 두 애플리케이션 모두 각자의 설정에서 해당 라이브러리를 공유하도록 선언하면 여전히 공유할 수 있습니다.

예시: `app1`과 `app2`가 모두 유틸리티 라이브러리 `lodash`를 사용한다고 가정해 봅시다.

`app1`의 Webpack 설정 (lodash 추가):

            
// ... within ModuleFederationPlugin for app1
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

`app2`의 Webpack 설정 (lodash 추가):

            
// ... within ModuleFederationPlugin for app2
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

이 경우, 컨테이너가 `lodash`를 명시적으로 공유하지 않더라도, `app1`과 `app2`는 동일한 브라우저 컨텍스트에서 로드된다면 서로 `lodash`의 단일 인스턴스를 공유할 수 있습니다.

버전 불일치 처리하기

의존성 공유에서 가장 흔한 문제 중 하나는 버전 호환성입니다. 만약 `app1`이 `react` v18.1.0을 요구하고 `app2`가 `react` v18.2.0을 요구한다면 어떻게 될까요? 모듈 페더레이션은 이러한 시나리오를 관리하기 위한 강력한 전략을 제공합니다.

1. 엄격한 버전 매칭 (`requiredVersion`의 기본 동작)

정확한 버전(예: '18.1.0')이나 엄격한 범위(예: '^18.1.0')를 지정하면, 모듈 페더레이션은 이를 강제합니다. 만약 애플리케이션이 이미 사용 중인 다른 애플리케이션의 요구사항을 만족하지 못하는 버전의 공유 의존성을 로드하려고 하면, 오류가 발생할 수 있습니다.

2. 버전 범위 및 폴백

requiredVersion 옵션은 시맨틱 버저닝(SemVer) 범위를 지원합니다. 예를 들어, '^18.0.0'은 18.0.0부터 19.0.0 미만까지의 모든 버전을 의미합니다. 여러 애플리케이션이 이 범위 내의 버전을 요구하는 경우, 모듈 페더레이션은 일반적으로 모든 요구사항을 만족하는 가장 높은 호환 버전을 사용합니다.

다음과 같은 경우를 고려해 봅시다:

• 컨테이너: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

만약 컨테이너가 먼저 로드되면, `react` v18.0.0(또는 실제로 번들링한 버전)을 설정합니다. `app1`이 `^18.1.0`으로 `react`를 요청할 때, 컨테이너의 버전이 18.1.0보다 낮으면 실패할 수 있습니다. 그러나 `app1`이 먼저 로드되어 `react` v18.1.0을 제공하고, 그 다음 `app2`가 `^18.2.0`으로 `react`를 요청하면, 모듈 페더레이션은 `app2`의 요구사항을 만족시키려고 시도할 것입니다. 만약 `react` v18.1.0 인스턴스가 이미 로드되어 있다면, v18.1.0이 `^18.2.0`을 만족하지 않기 때문에 오류를 발생시킬 수 있습니다.

이를 완화하기 위해, 공유 의존성을 가장 넓은 허용 가능한 버전 범위로 정의하는 것이 가장 좋은 방법이며, 이는 보통 컨테이너 애플리케이션에서 이루어집니다. 예를 들어, '^18.0.0'을 사용하면 유연성을 확보할 수 있습니다. 만약 특정 원격 애플리케이션이 더 새로운 패치 버전에 대한 강력한 의존성을 가지고 있다면, 해당 버전을 명시적으로 제공하도록 구성해야 합니다.

3. `shareKey`와 `shareScope` 사용하기

모듈 페더레이션은 또한 모듈이 공유되는 키와 그것이 속한 스코프를 제어할 수 있게 해줍니다. 이는 고급 시나리오에서 유용할 수 있으며, 예를 들어 동일한 라이브러리의 다른 버전을 다른 키로 공유하는 경우에 사용됩니다.

4. `strictVersion` 옵션

strictVersion이 활성화되면(`requiredVersion`의 기본값), 모듈 페더레이션은 의존성이 만족될 수 없을 때 오류를 발생시킵니다. strictVersion: false로 설정하면 더 관대한 버전 처리를 허용할 수 있으며, 이 경우 모듈 페더레이션은 새로운 버전이 없을 때 이전 버전을 사용하려고 시도할 수 있지만, 이는 런타임 오류로 이어질 수 있습니다.

공유 스코프 사용을 위한 모범 사례

모듈 페더레이션의 공유 스코프를 효과적으로 활용하고 일반적인 함정을 피하려면, 다음 모범 사례를 고려하십시오:

1. 공유 의존성 중앙화: 주요 애플리케이션(주로 컨테이너 또는 전용 공유 라이브러리 애플리케이션)을 지정하여 프레임워크(React, Vue, Angular), UI 컴포넌트 라이브러리, 상태 관리 라이브러리와 같은 공통적이고 안정적인 의존성의 진실 공급원으로 삼으십시오.
2. 넓은 버전 범위 정의: 주요 공유 애플리케이션에서 공유 의존성에 대해 SemVer 범위(예: '^18.0.0')를 사용하십시오. 이를 통해 다른 애플리케이션들이 전체 생태계에 걸쳐 엄격한 업데이트를 강제하지 않고도 호환되는 버전을 사용할 수 있습니다.
3. 공유 의존성 명확히 문서화: 어떤 의존성이 공유되는지, 그 버전은 무엇인지, 그리고 어떤 애플리케이션이 그것들을 공유하는 책임이 있는지에 대한 명확한 문서를 유지하십시오. 이는 팀이 의존성 그래프를 이해하는 데 도움이 됩니다.
4. 번들 크기 모니터링: 애플리케이션의 번들 크기를 정기적으로 분석하십시오. 모듈 페더레이션의 공유 스코프는 공통 의존성이 외부화되면서 동적으로 로드되는 청크의 크기를 줄여야 합니다.
5. 비결정적 의존성 관리: 자주 업데이트되거나 불안정한 API를 가진 의존성에 주의하십시오. 이러한 의존성을 공유하면 더 신중한 버전 관리와 테스트가 필요할 수 있습니다.
6. `eager: true` 신중하게 사용하기: `eager: true`는 의존성이 조기에 로드되도록 보장하지만, 과도하게 사용하면 초기 로드 크기가 커질 수 있습니다. 애플리케이션 시작에 필수적인 중요한 라이브러리에만 사용하십시오.
7. 테스트는 중요합니다: 마이크로프론트엔드의 통합을 철저히 테스트하십시오. 공유 의존성이 올바르게 로드되고 버전 충돌이 원활하게 처리되는지 확인하십시오. 통합 및 엔드투엔드 테스트를 포함한 자동화된 테스트는 필수적입니다.
8. 단순성을 위해 모노레포 고려: 모듈 페더레이션을 시작하는 팀의 경우, 모노레포(Lerna 또는 Yarn Workspaces와 같은 도구 사용) 내에서 공유 의존성을 관리하면 설정을 단순화하고 일관성을 보장할 수 있습니다. `packageDir` 옵션은 여기서 특히 유용합니다.
9. `shareKey` 및 `shareScope`로 엣지 케이스 처리: 복잡한 버전 관리 시나리오에 직면하거나 동일한 라이브러리의 다른 버전을 노출해야 하는 경우, 더 세분화된 제어를 위해 `shareKey` 및 `shareScope` 옵션을 탐색하십시오.
10. 보안 고려사항: 공유 의존성이 신뢰할 수 있는 소스에서 가져오는지 확인하십시오. 빌드 파이프라인 및 배포 프로세스에 대한 보안 모범 사례를 구현하십시오.

글로벌 영향 및 고려사항

글로벌 개발팀에게 모듈 페더레이션과 그 공유 스코프는 다음과 같은 상당한 이점을 제공합니다:

• 지역 간 일관성: 지리적 위치에 관계없이 모든 사용자가 동일한 핵심 의존성으로 애플리케이션을 경험하도록 보장하여 지역적 불일치를 줄입니다.
• 더 빠른 반복 주기: 다른 시간대에 있는 팀들이 공통 라이브러리를 복제하거나 의존성 버전에 대해 서로의 작업을 방해할 걱정 없이 독립적인 기능이나 마이크로프론트엔드에서 작업할 수 있습니다.
• 다양한 네트워크에 최적화: 공유 의존성을 통해 전체 다운로드 크기를 줄이는 것은 세계 여러 지역에서 흔히 볼 수 있는 느리거나 종량제 인터넷 연결을 사용하는 사용자에게 특히 유용합니다.
• 간소화된 온보딩: 대규모 프로젝트에 새로 합류하는 개발자들은 공통 라이브러리가 명확하게 정의되고 공유될 때 애플리케이션의 아키텍처와 의존성 관리를 더 쉽게 이해할 수 있습니다.

그러나 글로벌 팀은 다음 사항에도 유의해야 합니다:

• CDN 전략: 공유 의존성이 CDN에 호스팅되는 경우, CDN이 모든 대상 지역에 대해 양호한 글로벌 도달 범위와 낮은 지연 시간을 갖도록 하십시오.
• 오프라인 지원: 오프라인 기능이 필요한 애플리케이션의 경우, 공유 의존성과 그 캐싱 관리가 더 복잡해집니다.
• 규제 준수: 라이브러리 공유가 다른 관할권의 관련 소프트웨어 라이선스 또는 데이터 개인 정보 보호 규정을 준수하는지 확인하십시오.

일반적인 함정과 이를 피하는 방법

1. 잘못 구성된 `singleton`

문제점: 단 하나의 인스턴스만 가져야 하는 라이브러리에 대해 singleton: true 설정을 잊는 경우.

해결책: 애플리케이션 전반에 걸쳐 고유하게 공유하려는 프레임워크, 라이브러리 및 유틸리티에 대해 항상 singleton: true를 설정하십시오.

2. 일관성 없는 버전 요구사항

문제점: 다른 애플리케이션들이 동일한 공유 의존성에 대해 매우 다르고 호환되지 않는 버전 범위를 지정하는 경우.

해결책: 특히 컨테이너 앱에서 버전 요구사항을 표준화하십시오. 넓은 SemVer 범위를 사용하고 예외 사항은 문서화하십시오.

3. 비필수적인 라이브러리의 과도한 공유

문제점: 모든 작은 유틸리티 라이브러리를 공유하려고 시도하여 복잡한 구성과 잠재적인 충돌을 초래하는 경우.

해결책: 크고, 공통적이며, 안정적인 의존성 공유에 집중하십시오. 작고 드물게 사용되는 유틸리티는 복잡성을 피하기 위해 로컬에 번들링하는 것이 더 나을 수 있습니다.

4. `remoteEntry.js` 파일을 올바르게 처리하지 못하는 경우

문제점: `remoteEntry.js` 파일이 소비 애플리케이션에 접근할 수 없거나 올바르게 제공되지 않는 경우.

해결책: 원격 엔트리에 대한 호스팅 전략이 견고하고 `remotes` 구성에 지정된 URL이 정확하고 접근 가능한지 확인하십시오.

5. `eager: true`의 영향 무시

문제점: 너무 많은 의존성에 `eager: true`를 설정하여 초기 로드 시간이 느려지는 경우.

해결책: 애플리케이션의 초기 렌더링이나 핵심 기능에 절대적으로 중요한 의존성에만 `eager: true`를 사용하십시오.

결론

자바스크립트 모듈 페더레이션의 공유 스코프는 현대적이고 확장 가능한 웹 애플리케이션, 특히 마이크로프론트엔드 아키텍처 내에서 구축하기 위한 강력한 도구입니다. 효율적인 의존성 공유를 가능하게 함으로써 코드 중복, 비대화, 불일치 문제를 해결하여 성능과 유지보수성을 향상시킵니다. shared 옵션, 특히 singleton 및 requiredVersion 속성을 이해하고 올바르게 구성하는 것이 이러한 이점을 얻는 열쇠입니다.

글로벌 개발팀이 마이크로프론트엔드 전략을 점점 더 많이 채택함에 따라, 모듈 페더레이션의 공유 스코프를 마스터하는 것이 무엇보다 중요해졌습니다. 모범 사례를 준수하고, 버전 관리를 신중하게 하며, 철저한 테스트를 수행함으로써, 이 기술을 활용하여 다양한 국제 사용자 기반에 효과적으로 서비스를 제공하는 견고하고 고성능이며 유지보수 가능한 애플리케이션을 구축할 수 있습니다.

공유 스코프의 힘을 받아들이고, 조직 전체에서 더 효율적이고 협력적인 웹 개발을 위한 길을 닦으십시오.